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DETAILED ACTION 

1 . Claims 1-30 are subject to examination. 

Response to Arguments 

2. Applicant's arguments filed 7/27/2006, pages 8-14 have been fully considered but 
they are not persuasive. Therefore, rejection of claims 1-30 is maintained. 

Applicant argues (1), "the cited reference do not teach or disclose that requests by 
a scheduler, assignment of a virtual IP address to said scheduler, said scheduler is 
designated as active scheduler for a load balancing array as claimed in claims 1 and 16" 

The examiner respectfully disagrees in response to applicant's arguments. The 
limitations, "requests by a scheduler, assignment of 5 , has been newly added, which alters 
the scope of the claimed limitations and which is addressed by the new ground(s) of 
rejection (please refer to the below rejections of this office action). Therefore, the 
rejection is maintained. 

Claim Objections 

3. Following claims are objected to because of the following informalities: 
Claim 1 mentions, "the steps of 5 at line 2, which should be —a step of~ 

Claim 16 mentions, "a module for a requesting, by a scheduler" at line 3. It is not 
clear whether the module is requesting or the scheduler is requesting. 
Appropriate correction is required. 
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Claim Rejections - 35 USC § 112 
The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter, which the applicant regards as his invention. 

4. Following claims are rejected under 35 U.S.C. 1 12, second paragraph, as being 

indefinite for failing to particularly point out and distinctly claim the subject matter 

which applicant regards as the invention. 

Claim 1 at line 13 recites the limitations, "said client". There is insufficient 
antecedent basis for this limitation in the claim (Please see MPEP 706.03(d). Since, 
multiple "clients" exist (line 5 requesting clients (multiple), line 8 requesting client) in 
the claim, it is not clear which "client" is referred by the limitations in the claim. 

Claim 3 recites the limitations, "the failure of said scheduler". There is 
insufficient antecedent basis for this limitation in the claim (Please see MPEP 706.03(d). 

Claim 4 recites the limitations, "the failure of other load balancing servers". 
There is insufficient antecedent basis for this limitation in the claim (Please see MPEP 
706.03(d). 

Regarding claims 7, 8, 13, 22, 23 and 28 the phrase "if renders the claim 
indefinite because it is unclear whether the limitations following the phrase are part of the 
claimed invention. See MPEP § 2173.05(d). 

Regarding claims 12, the phrase "when" renders the claim indefinite because it is 
unclear whether the limitations following the phrase are part of the claimed invention. 
See MPEP § 2173.05(d). 
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Claim Rejections - 35 USC § 101 
35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

5. Claims 1-15 contain single requesting step that do not produce a tangible result. 
Requesting alone is not producing a tangible result. It's not until the result of the 
requesting is used in a disclosed practical application or at least made available for use in 
a disclosed practical application that it becomes a tangible result, which enables any 
usefulness of having done the requesting to be realized (please see the claimed subject 
matter of claims 1-15). Further no steps are present to do the processing to accomplish 
the routing of packets. Please note that lines 5-13 (wherein) are not steps. 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

7. Claims 1-4, 7, 9, 13, 16-19, 22, 23 and 28 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Zisapel-Radware in view of Hasett-PointCast and "Official 
Notice". 

8. As per claims 1 and 16, Zisapel-Radware clearly teaches a process and an 
apparatus (e.g., figure 1C, abstract) to implement routing packets through a load 
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balancing array of servers across a network in a computer environment (e.g., router 
balancing load among cluster of servers over the network, figures 1 A - 1C, paragraph 33, 
page 3), 

a scheduler that is designated as active scheduler for a load balancing array (e.g., 
usage of load balancing servers, content servers, SI, Sn, figures 1 A - 1C, paragraph 33, 
page 3); 

wherein all incoming packets from requesting clients destined for the load 
balancing array are routed through said scheduler (e.g., LB1 load balancing server also 
scheduling client requests for LB2 load balancing server, figures 1 A - 1C, paragraphs 33 
and 34, page 3); 

wherein said scheduler routes and load balances a request packet from a 
requesting client (e.g., client requests, paragraphs 33 and 34, page 3) to a load balancing 
server (e.g., LB1 load balancing server also scheduling client requests for LB2 load 
balancing server, figures 1 A - 1C, paragraph 33, page 3); 

wherein said load balancing server routes and load balances said request packet to 
a back end Web server (e.g., LB2 load balancing server balancing load among content 
servers, SI, Sn, figures 1A - 1C, paragraph 33, page 3); 

wherein said back end Web server's response packet to said request packet is sent 
to said load balancing server (e.g., SI, Sn, content servers supporting client requests 
through LB2 load balancing server, paragraphs 8-10, pagel); and 

wherein said load balancing server sends said response packet directly to said 
client (e.g., LB2 load balancing server forwarding response from content servers, SI, Sn, 
to the clients, paragraphs 8-10, pagel). 
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Zisapel-Radware also teaches handling of multiple requests for a client (e.g., 
paragraph 36, page 3). 

However, Zisapel-Radware does not specifically mention about a request 
containing multiple packets and a scheduler supporting multiple clients . 

Hasett-PointCast clearly teaches a request containing multiple packets (e.g., 
abstract, col., 7, lines 5 - 40, col., 3, lines 34 - 65) and a scheduler supporting multiple 
clients (e.g., abstract, col., 7, lines 5 - 40, col., 3, lines 34 - 65). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of Zisapel-Radware with Hasett-PointCast 
in order to facilitate the scheduler to support multiple clients because the requests from 
the multiple clients would be processed by the scheduler. A request having multiple 
packets would help the request communicated from a client to the scheduler. The 
scheduler would receive requests from the clients and would forward the requests so that 
the requests from the clients are properly handled. 

Zisapel-Radware and Hasett-PointCast do not specifically mention about usage of 
the virtual IP address and requesting by a routing/load balancing device an assignment of 
the virtual IP address for itself. 

"Official Notice" is taken that both the concept and advantages of providing usage 
of the virtual IP address and requesting by a routing/load balancing device an assignment 
of the virtual IP address for itself is well known and expected in the art. For example, 
Brack et al., discloses these limitations, Rainfinity Inc, e.g., col., 30, lines 24-43; 
Anerousis et al., AT&T, 2004/0210670 also discloses these limitations, e.g., paragraphs 
82, 85 and 131; Brack et al., 6,801,949, Rainfinity Inc also discloses these limitations, 
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e.g., col, 36, line 26 - col, 37, line 19; Davies et al., 6,108,701 also discloses these 
limitations, e.g., col., 5, lines 22 - 35; Anerousis et al., 6,760,775, AT&T, also discloses 
these limitations, e.g., usage of hierarchical CPU scheduler, HTTP redirect capabilities, 
redirect proxy acting as a virtual host for redirecting all network service requests, col., 13, 
lines 40 - 54; Chaganty et al., Avaya, also discloses these limitations, col., 24, lines 23- 
35; Devine et al., Worldcom Inc., 2003/0191970 also discloses these limitations, 
paragraph 145; Gourlay, 6,850,980, Cisco, also discloses these limitations, col, 1, lines 
39 - 56 of "Background of the Invention". 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include the virtual IP address and requesting by a routing/load 
balancing device an assignment of the virtual IP address for itself with the teachings of 
Zisapel-Radware and Hasett-PointCast in order to facilitate requesting and assigning the 
virtual IP address because the virtual IP address would be utilized to communicate 
information from other devices on network to the routing/load balancing device. Using a 
well-known concept of having a single virtual IP address that can be used by multiple 
devices wherein one of the devices is assigned the VIP at a time would enhance the 
routing/load balancing device to receive packets from devices over the network using the 
assigned virtual IP address in order for routing the received packets. Using the virtual IP 
address routing/load balancing device would communicate with remote device over the 
network. The assigned virtual IP address would provide a client device to send a request 
to the routing/load balancing device. 
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9. As per claims 2 and 17, Zisapel-Radware and Hasett-PointCast teach the claimed 
limitations as rejected above. Zisapel-Radware also teaches the following: 

scheduler is a load balancing server and routes and load balances client requests 
to itself (e.g., LB1 load balancing server scheduling client requests for itself, figures 1 A - 
1C, paragraph 33, page 3). 

10. As per claims 3 and 18, Zisapel-Radware and Hasett-PointCast teach the claimed 
limitations as rejected above. Zisapel-Radware also discloses electing a load balancing 
server (e.g., selection of LB1 or LB2 or LB3, paragraphs 33 and 42) among a plurality of 
load balancing servers (e.g., LB1 or LB2 or LB3, paragraphs 33 and 42) as a new 
scheduler (e.g., usage of LB1 or LB2 or LB3 upon availability for new (next) scheduling, 
paragraphs 33 and 42). (Note: the new scheduler is not limited to replacing another 
scheduler). 

However, Zisapel-Radware and Hasett-PointCast do not specifically mention 
about the use of detecting the failure of the server. "Official Notice" is taken that both the 
concept and advantages of providing to detect the failure of the server is well known and 
expected in the art. For example, Coile et al., 6,108,300 (Hereinafter Coile) teaches these 
limitations, e.g., col., 5, lines 3 - 24, e.g., col., 6, lines 40 - 62, col., 8, lines 2 - 28. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include detecting the failure of the server with the teachings of 
Zisapel-Radware and Hasett-PointCast in order to facilitate handling of system 
performance in an event of the scheduler failure because upon failure of the scheduler the 
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system would know what client requests are not handled by the failed scheduler. The 
system would have another server to handle the job of the failed server. 

11. As per claims 4 and 19, Zisapel-Radware and Hasett-PointCast teach the claimed 
limitations as rejected above. However, Zisapel-Radware and Hasett-PointCast do not 
specifically mention about the use of server detecting the failure of other load balancing 
servers and the server stops routing packets to any failed load balancing servers. 
"Official Notice" is taken that both the concept and advantages of providing server 
detecting the failure of other load balancing servers and the server stops routing packets 
to any failed load balancing servers, is well known and expected in the art. For example, 
Coile et al, 6,108,300 (Hereinafter Coile) teaches limitations, "server detecting the 
failure of other load balancing servers (e.g., col., 12, lines 35 - 54, col., 6, lines 40 - 62, 
col., 8, lines 2 - 28)" and "the server stops routing packets to any failed load balancing 
servers/back end Web servers (e.g., col, 12, lines 35 - 54, e.g., col., 6, lines 40 - 62, col., 
8, lines 2 -28)". 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include server detecting the failure of other load balancing servers 
and the server stops routing packets to any failed load balancing servers, with the 
teachings of Zisapel-Radware and Hasett-PointCast in order to facilitate assigning client 
requests to another load balancing server instead of the failed load balancing server 
because stopping to route packets to the failed load balancing server would prevent 
dropping packets. Rerouting to the packets to the other load balancing server will help 
process the client requests. 
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12. As per claims 7, 8, 22 and 23, Zisapel-Radware and Hasett-PointCast teach the 
claimed limitations as rejected above. However, Zisapel-Radware and Hasett-PointCast 
do not specifically mention about the use of server decrypting and encrypting packet for 
an SSL session. "Official Notice" is taken that both the concept and advantages of 
providing server decrypting and encrypting packet for an SSL session, is well known and 
expected in the art. For example, Hankinson et al., 6,799,202 (Hereinafter Hankinson) 
teaches limitations, "server decrypting and encrypting packet for SSL session (e.g., col., 
3, lines 2 -65)". 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include server decrypting and encrypting packet for an SSL 
session, with the teachings of Zisapel-Radware and Hasett-PointCast in order to facilitate 
secure communicating between the client and the Web server because for processing and 
forwarding the packet to the Web server, the load balancing server will decrypt the 
packet when it receives from the client. The load balancing server will receive the 
response packet from the Web server, and it will encrypt the response packet before 
sending to the client. Using well-known SSL session implementation, the web server and 
the client will have direct secure communication. 

13. As per claims 13 and 28, Zisapel-Radware and Hasett-PointCast teach the claimed 
limitations as rejected above. However, Zisapel-Radware and Hasett-PointCast do not 
specifically mention about the use of detecting and stop routing request packets to failed 
back end Web servers. "Official Notice" is taken that both the concept and advantages of 
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providing detecting and stop routing request packets to failed back end Web servers is 
well known and expected in the art. For example, Coile et al., 6,108,300 (Hereinafter 
Coile) teaches limitations, "server detecting the failure of other load balancing servers 
(e.g., col., 12, lines 35 - 54, col., 6, lines 40 - 62, col, 8, lines 2 - 28)" and "the server 
stops routing packets to any failed load balancing servers/back end Web servers (e.g., 
col., 12, lines 35 - 54, e.g., col., 6, iines 40 - 62, col., 8, lines 2 - 28)". 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include detecting and stop routing request packets to failed back 
end Web servers with the teachings of Zisapel-Radware and Hasett-PointCast in order to 
facilitate accessing the other web server in an event of the web server failure because 
upon failure of the web server, other web server would help support the client requests. 
By stopping to route the packets to the failed web server would help prevent packets from 
dropping and the other web server would then handle the client requests. 

14. Claims 5, 6, 14, 15, 20, 21, 29, 30, are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Zisapel-Radware and Hasett-PointCast in view of Masters 6,374,300 
(Hereinafter Masters). 

15. As per claims 5, 6, 14, 15, 20, 21, 29, 30, Zisapel-Radware and Hasett-PointCast 
teach the claimed limitations as rejected above. However, Zisapel-Radware and Hasett- 
PointCast do not specifically mention about the server scheduling sessions to servers 
based on a cookie or session ID and use of cookie injection to map a client to a specific 
server. 
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Masters clearly teaches about the concept of server scheduling sessions to servers 
based on a cookie or session ID (e.g., abstract, col., 10, lines 8 - 61), and use of cookie 
injection to map a client to a specific server (e.g., abstract, col., 10, lines 8-61, col., 13, 
lines 1- 24), modify URLs in the HTML page in a packet to serve them from said content 
delivery network (e.g., col, 5, linesl4 - 61, col., 3, lines 21 - 50), HTML pages that have 
modified URLs are cached to improve performance (e.g., abstract, col., 10, lines 8 - 61, 
col., 2, lines 24 - page 4, line 34, col., 7, lines 1-16). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of Zisapel-Radware and Hasett-PointCast 
with Masters in order to facilitate scheduling based on cookie for persistent connection 
with the web server because using the cookie the client request can be routed to a 
previously selected destination web server associated with the client. The client will be 
able to continue using the same web server support. As per Masters teachings, the cookie 
information can be manipulated as necessary. Hence, the client will be able to continue 
communicating with the server in a direct persistent manner. 

16. Claims 9-12, 24-27, are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Zisapel-Radware, Hasett-PointCast and "Official Notice" in view of Masters 
6,374,300 (Hereinafter Masters). 

17. As per claims 9-12, 24-27, Zisapel-Radware and Hasett-PointCast teach the 
claimed limitations as rejected above. However, Zisapel-Radware and Hasett-PointCast 
do not specifically mention about the client keeping connection alive with the server. 
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"Official Notice" is taken that both the concept and advantages of the client keeping 
connection alive with server, is well known and expected in the art. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to include the client keeping connection alive with the server, with 
the teachings of Zisapel-Radware and Hasett-PointCast in order to facilitate secure 
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session implementation, the web server and the client will have direct secure 
communication as long as the connection between the web server and the client is alive. 

Zisapel-Radware and Hasett-PointCast do not specifically mention about URL 
based scheduling of packets and the load balancing server performing hash scheduling of 
packets. Masters teaches about URL based scheduling of packets (e.g., col., 5, lines 18 - 
65), persistent connections in its paths when required (e.g., col., 5, lines 22 - 59, col., 6, 
lines 8-31) and the load balancing server performing hash scheduling of packets (e.g., 
col., 15, lines 45 - col., 16, lines 21) and uses hash group based persistence to maintain 
its persistence tables (e.g., col, 5, lines 22 - 59, col, 15, line 57 - col., 16, line 24). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of Zisapel-Radware and Hasett-PointCast 
with Masters in order to facilitate secure communicating between the client and the Web 
server because the URL information in the https packet would provide information of the 
resource, which the client needs to access. The scheduling with hashing of packets will 
provide direct secure communication between the web server and the client. 
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Conclusion 

Examiner has cited particular columns and line numbers and/or paragraphs and/or 
sections and/or page numbers in the reference(s) as applied to the claims above for the 
convenience of the applicant. Although the specified citations are representative of the 
teachings of the art and are applied to the specific limitations within the individual claim, 
other passages and figures may apply as well. It is respectfully requested from the 
applicant in preparing responses, to fully consider the references in entirety, as potentially 
teaching, all or part of the claimed invention, as well as the context of the passage, as 
taught by the prior art or disclosed by the Examiner. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Haresh Patel whose telephone number is (571) 272-3973. 
The examiner can normally be reached on Monday, Tuesday, Thursday and Friday from 
10:00 am to 8:00 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone number 
for the organization where this application or proceeding is assigned is (571) 273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 

\ba$es\ fate! 
Haresh Patel 

September 12,2006 



